(19) 



J) 



Euiopaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(11) EP1 199 874 A2 

EUROPEAN PATENT APPLICATION 



(43) Date of publication: 

24.04.2002 Bulletin 2002/17 

(21) Application number: 01124147.8 

(22) Dateof filing: 10.10.2001 



(51) lntCl7: H04N 1/00 



(84) Designated Contracting States: 


(72) 


Inventors: 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


• 


Camara, Franc. J. 


MC NL PT SE TR 




Redmond, Washington 98052 (US) 


Designated Extension States: 


• 


Yuan, Po 


AL LT LV MK RO SI 




Renton, Washington 98056 (US) 




• 


Sadovsky, Vladimir 


(30) Priority: 17.10.2000 US 240772 P 




Bellevue, Washington 98005 (US) 


07.09.2001 US 949166 








(74) 


Representative: Griineclter, Kinkeldey, 


(71) Applicant: MICROSOFT CORPORATION 




Stockmair & Schwanhausser Anwaltssozietat 


Redmond, WA 98052 (US) 




Maximiiianstrasse 58 
80538 Munchen (DE) 



(54) System and method for controlling mass storage class digital Imaging devices 



(57) A method is provided for controlling a Mass 
StorageClass Digital Imaging Device using a SCSI pass 
through protocol. The protocol is based on industry 
standard SCSI protocol with modifications and exten- 
sions to allow transparent communication over a medi- 
um and is referred to as SCSI Pass Through (SPT). This 
protocol defines a set of commands that are initiated in 
a computer. The commands also include and extend in- 



dustry standard Picture Transfer Protocol and are tar- 
geted for application and execution in a Mass Storage 
Class Digital Imaging Device. The invention includes the 
definition of data buffers in the fonn of data structures 
that can be used for passing and receiving infomnation 
related to the digital imaging device. The protocol is ap- 
plicable to communication mediums that can be utilized 
in connecting any digital storage device to a computing 
device. 
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Description 

Cross Reference To Related Applications 

5 [0001] This application claims the benefit of U.S. provisional application Serial Number 60/240772 filed October 1 7, 
2000. 

Field Of The Invention 

10 [0002] The present invention relates to computer software. More specifically, this invention relates to a system and 
method for communicating with and controlling mass storage class digital imaging devices. 

Background Of The invention 

15 [0003] A computer system that can communicate with a mass storage class digital imaging device such as a digital 
camera is a common arrangement. For example, there are several digital cameras that communicate with personal 
computers (PCs) however, the methods for accomplishing communication and control are proprietary to each manu- 
facturer. This essentially poses a problem for users because of the multitude of associated interfaces and drivers that 
are required for the various brands and models of cameras on the market. 

20 [0004] One attempt to resolve this problem was the introduction of a standard protocol to be utilized by manufacturers, 
namely the USB Mass Storage Class Device specification. The implementation of a digital camera in accordance with 
the afore mentioned specification provides the benefit of allowing an operating system with native driver support to 
provide 'Plug and Play' experience for the user The implementation also allows such a conforming device to appear 
on the PC as a storage device and allows the user to copy files to or from the device. However, a digital camera 

25 potentially has several files which are not related to stored images and as such, the user will be presented with a 
multitude of files through which they must navigate in order to obtain the image file of interest. A further drawback of 
the implementation of the USB Mass Storage Class Device specification is the inability to actually control the device. 
For example, under existing support for cameras, it is not possible to set the clock on the camera from PC. This and 
other specific controls that could benefit a user are not available under the presently available implementations for 

30 unifomn camera support. For example, a user may desire to perform live capture, query the camera or adjust a camera 
property setting. Presently, non of these functions are possible with the existing USB Mass Storage Class Device 
specification. Instead, a specific driver or application from the manufactures is required in order to accomplish these 
tasks. 

[0005] Accordingly, there exists a need for a method that allows Mass Storage Class Digital Imaging Devices, par- 
35 ticularly cameras to take advantage of interfaces and features that are a part of the user experience. An extensible 
control protocol is needed for controlling most common tasks in these digital content devices such as a Mass Storage 
Class Digital Camera, without the need for manufacturers to develop custom control software. In other words, manu- 
facturers that implement the control protocol on their devices will be able to benefit from the ability to have the device 
controlled by an operating system application such as Windows Image Acquisition wizard (Wl A) or by other programs 
40 through an application program interface (API) defined within an operating' system. 

Summary Of The Invention 

[0006] In one aspect, the present invention is directed to a method of communicating with a Mass Storage Class 
45 Digital imaging Device. The method provides a protocol that allows the control of a digital imaging device that is coupled 
to a computer. The protocol is based on industry standard SCSI protocol with modifications and extensions to allow 
transparent communication over a connection medium and is referred to as SCSI Pass Through (SPT). 
[0007] In another aspect, the present invention is directed to the definition of a set of commands that are initiated in 
a computer, include and extend industry standard Picture Transfer Protocol and are targeted for application and exe- 
50 cution in a Mass Storage Class Digital Camera. 

[0008] In a further aspect, the present invention is directed to the control of a digital camera using the afore mentioned 
protocol and commands which together are designated as the SCSI Pass Through Camera Commands Protocol 
(SPTCCP). 

[0009] In yet another aspect, the present Invention is directed to the definition of data buffers in the form of data 
55 structures that can be used for passing and receiving information related to the digital imaging device. 
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Brief Description Of The Several Views Of The Drawings 

[0010] The present invention is described in detail below with reference to the attached drawing figures, wherein: 

5 FIG, 1 is ablock diagram of asuitable computing system environmentforuse in implementingthe present Invention; 

FIG. 2 is a block diagram illustration of the architecture of communication between an application program and a 
USB IVIass Storage Class Digital Camera device (MSG). 

FIG 3 is an illustration of a data structure utilized in sending commands to MSG. 
10 Detailed Description Of The Invention 

[0011] The present invention provides a system and method for controlling a Mass Storage Class Digital Imaging 
Device such as a Mass Storage Class Digital Camera (MSG) or other similar digital content devices that contain a 
structured file system, such as certain types of hard drives, compact disk devices etc. The particular embodiments 

15 descnbod horcm arc intended in all respects to be illustrative ratherthan restrictive. Alternate embodiments will become 
apparent to those skilled in the art to which the present invention pertains without departing from Its scope. FIG. 1 
illustrates an example of a suitable computing system environment in which the invention may be implemented. The 
computing system environment is only one example of a suitable computing envlronnnent and is not intended to suggest 
any limiiHiion rts to the scope of use or functionality of the invention. Neither should the computing environment be 

20 interpieled as* tiaving any dependency or requirement relating to any one or connbination of components illustrated in 
the exemplary operating environment. 

[00121 The invention is operational with numerous other general purpose or special purpose computing system en- 
vironments or configurauons. Examples of well known computing systems, environments, and/or configurations that 
may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand- 
25 held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, 
network PCs. minicomputers, mainframe computers, distributed computing environments that include any of the above 
systems or devices, and the like. 

[001 3] The invention may be described in the general context of computer-executable instructions, such as program 
modules, being executed by a computer. Generally, program modules include routines, programs, objects, components,. 
30 data structures, etc. that perfonm particular tasks or implement particular abstract data types. The invention may also 
be practiced in distributed computing environments where tasks are perfomned by remote processing devices that are 
linked through a communications network. In a distributed computing environment, program modules may be located 
in both local and remote computer storage media including memory storage devices. 

[0014] With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose 
35 computing device in theform of a computer 20. Components of computer 20 include, but are not limited to, a processing 
unit 22. a system memory 24. and a system bus 26 that couples various system components including the system 
memory to the processing unit 22. The system bus 26 may be any of several types of bus structures including a memory 
bus or memory controller a peripheral bus, and a local bus using any of a variety of bus architectures. By way of 
example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus. Micro Channel Ar- 
40 chitecture (MCA) bus, Enhanced ISA (EISA) bus. Video Electronics Standards Association (VESA) local bus, and 
Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus. 

[0015] Computer 20 typically includes a variety of computer readable media. Computer readable media can be any 
available media that can be accessed by computer 20 and includes both volatile and nonvolatile media, removable 
and non-removable media. By way of example, and not limitation, computer readable media may comprise computer 

45 storage media and communication media. Computer storage media Includes both volatile and nonvolatile, removable 
and non-removable media implemented in any method or technology for storage of infonnation such as computer 
readable instructions, data structures, program modules or other data. Computer storage media includes, but is not 
limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) 
or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage 

so devices, or any other medium which can be used to store the desired infonmation and which can be accessed by 
computer 20. Communication media typically embodies computer readable instructions, data structures, program mod- 
ules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any 
information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics 
set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, com- 

55 munication media includes wired media such as a wired network or direct wired connection, and wireless media such 
as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within 
the scope of computer readable media. 

[0016] The system memory 24 includes computer storage media in the form of volatile and/or nonvolatile memory 
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such as read only memory (ROM) 28 and random access memory (RAM) 30. A basic Input/output system 32 (BIOS), 
containing the basic routines that help to transfer infomnation between elements within computer 20, such as during 
start-up, is typically stored in ROM 28, RAM 30 typically contains data and/or program modules that are immediately 
accessible to and/or presently being operated on by processing unit 22. By way of example, and not limitation, FIG. 1 

5 illustrates operating system 46, application programs 48, other program modules 50, and program data 52. 

[0017] The computer 20 may also include other removable/non-removable, volatile/nonvolatile computer storage 
media. By way of example only, FIG. 1 illustrates a hard disk drive 34 that reads from or writes to non-removable, 
nonvolatile magnetic media, a magnetic disk drive 36 that reads from or writes to removable, nonvolatile magnetic disk 
38, and an optical disk drive 40 that reads from or writes to a removable, nonvolatile optical disk 42 such as a CD ROM 

10 or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used 
in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, 
digital video disks, digital video tape, Bemoulli cartridges, solid state RAM, solid state ROM, and the like. The hard 
disk drive 34, magnetic disk drive 36, and optical disk drive 40 are typically connected to the system bus 26 by a Small 
Computer System Interface (SCSI) 44. Alternatively, the hard disk drive 34, magnetic disk drive 36 and optical disk 

15 drive 40 may be connected to the system bus 26 by a hard disk drive interface, a magnetic disk drive interface, and 
an optical drive interface, respectively. 

[0018] The drives and their associated computer storage media discussed above and illustrated In FIG. 1 , provide 
storage of computer readable instructions, data structures, program modules and other data for the computer 20. In 
FIG. 1, for example, hard disk drive 34 is illustrated as storing operating system 46, application programs 48, other 
20 program modules 50, and program data 52. Note that these components can either be the same as or different from 
operating system 46, application programs 48, other program modules 50, and program data 52. A user may enter 
commands and infonnation into the computer 20 through input devices such as a keyboard 54 and pointing device 56, 
commonly refen-ed to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, 
joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the process- 
es jng unit 22 through a user input interface 58 or a serial port interface 60 that is coupled to the system bus, but may be 
connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A 
monitor 61 or other type of display device is also connected to the system bus 26 via an Interface, such as a video 
adapter 62. In addition to the monitor 61 , computers may also include other peripheral output devices such as speakers 
and printers, which may be connected through an output peripheral interface. 
30 [0019] The computer 20 may operate In a networked environment using logical connections to one or more remote 
computers, such as a remote computer 64. The remote computer 64 may be a personal computer, a server, a router, 
a network PC, a peer device or other common networi< node, and typically includes many or all of the elements described 
above relative to the computer 20, although only a memory storage device has been illustrated in FIG. 1 . The logical 
connections depicted in FIG. 1 include a local area network (LAN) 66 and a wide area networic (WAN) 68, but may 
35 also include other networi<s. Such networking environments are commonplace In offices, enterprise-wide computer 
networks, intranets and the Internet. 

[0020] When used in a LAN networi<ing environment, the computer 20 is connected to the LAN 66 through a network 
interface or adapter 70. When used in a WAN networking environment, the computer 20 typically includes a modem 
72 or other means for establishing communications over the WAN 68, such as the Intemet, The modem 72, which may 

40 be internal or external, may be connected to the system bus 26 via the serial port interface 60 or other appropriate 
mechanism. In a networked environment, program modules depicted relative to the computer 20, or portions thereof, 
may be stored In the remote memory storage device. By way of example, and not limitation, FIG. 1 illustrates remote 
application programs 48 as residing on nnemory device 64. it will be appreciated that the network connections shown 
are exemplary and other means of establishing a communications link between the computers may be used. 

45 [0021] Although many other internal components of the computer 20 are not shown, those of ordinary skill in the art 
will appreciate that such components and the Interconnection are well known. Accordingly, additional details concerning 
the internal construction of the computer 20 need not be disclosed In connection with the present invention. 
[0022] Those skilled in the art will understand that program modules such as the operating system 46, application 
programs 48 and data 52 are provided to the computer 20 via one of its memory storage devices, which may include 

50 ROM 28, RAM 30, hard disk drive 34, magnetic disk drive 36 or optical disk drive 40. Preferably, the hard disk drive 
34 is used to store data 52 and programs, including the operating system 46 and application programs 48. 
[0023] When the computer 20 is turned on or reset, the BIOS 32, which is stored in the ROM 28 instructs the process- 
ing unit 22 to load the operating system from the hard disk drive 34 into the RAM 30. Once the operating system 46 
is loaded in RAM 30, the processing unit 22 executes the operating system code and causes the visual elements 

55 associated with the user interface of the operating system 46 to be displayed on the monitor 61 . When an application 
program 48 is opened by a user, the program code and relevant data are read from the hard disk drive 34 and stored 
in RAM 30. 

[0024] In FIG. 2, an exemplary Illustration of an architecture for practicing the present invention is shown. There are 
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three components that make up the referenced architecture namely the user component 250, the Kernel component 
260 and the external USB Mass Storage Class Digital Camera (MSC) 224. The present invention is implemented in 
the user component 250 and uses existing architecture and methods within the Kernel 260, to communicate to finnware 
implementation within MSC 224 via a USB connection 222. It should be noted that the method of the present invention 
5 is independent of the physical bus medium by which a device is connected to the PC. The present invention is also 
applicable to perform other functions such as previously discussed, wherein a PC application such as Windows Explorer 
200 can be used via a file system interface 214 to communicate with the kernel and ultimately display a representation 
of the MSC device 224 and its associated file system 228. 

[0025] An embodiment of the present invention is directed at controlling the MSC device 224 through commands 
10 that are initiated by the Windows Image Acquisition (WIA) Wizard and other WIA enabled applications 21 0. The initiated 
commands are packaged as SCSI Pass-through commands by the Mass Storage Driver for Digital Cameras 212 and 
then transparently passed through the User mode file system Interface 214, the kernel components 260, and the USB 
Cable 222 into the MSC 224. The destination of the discussed commands is the control firmware 226 of the MSC 224. 
The firmware 226 contains manufacturer provided hardware and software that is aware and able to decipher the SCSI 
15 Pass Through Camera Commands Protocol (SPTCGP) to obtain the underlying device control command, such as 
standard Photo Imaging Marketing Association (PIMA) Picture Transfer Protocol (PTP) commands. The intended com- 
mand Is obtained and then executed by the control system 230 that is located within MSC 224. Any associated re- 
sponses are delivered back to the initiating application through a reverse of the process described above. 
[0026] In general, a protocol is defined by how information is exchanged between two or more devices by using 
20 various bits and elements of data that are structured and related to each other. Likewise, within SPTCCP protocol there 
is a defined data structure that is used for the exchange of infomnation. Because SPTCCP has as its underlying basis 
the SCSI protocol, the elements of the SPTCCP structure are derived from and compatible with those found in SCSI. 
A typical SCSI Pass Through data structure is defined as follows in C/G++ fonm: 



typdef Struct SCSI_PASS__THROUGH_DIRECT( 





USHORT 


Length; 




UCHAR 


ScsiStatus; 




UCHAR 


Pathid; 


30 


UCHAR 


Targetld; 




UCHAR 


Lun; 




UCHAR 


Cdblength; 




UCHAR 


SenselnfoLength; 


35 


UCHAR 


Datain; 




ULONG 


DataTransferLength; 




ULONG 


TimeoutValue; 




PVOID 


DataBuffer; 


40 


ULONG 


SenselnfoOffset; 




UCHAR 


Cdb[16]; 



}SCSI_PASS_THROUGH_DIRECT, * 



PSCSI PASS THROUGH_DIRECT 

45 — ~ 

[0027] The SCSI Pass Through structure including data buffers and other elements are translated into driver space 
and passed through to the target device. The DataBuffer and the Cdb from the structure shown above, contain the 
infonnation that define the command protocol for MSC 224. In other words SPTCCP is defined by the specification 

so and arrangement of bits within the Cdb and the DataBuffer. Cdb is the command descriptor block that contains the 
SCSI commands and parameters. In an embodiment of this invention, the 6-byte long Cdb otherwise known as Group 
0 Cdb, is used to define the protocol. Thus with reference to the pass through structure discussed and Illustrated above, 
only the first 6 bytes of the 16 byte Cdb within the pass througli structure are utilized. The content of these 6 bytes 
determine the type and fomiat of commands destined for the MSC 224. A discussion on the specific structure of Cdb 

55 is necessary to provide an understanding of the protocol of the present invention. 

[0028] FIG 3 is an illustration of the Cdb generally designated as 300, used by SPTCCP for communication with a 
MSC. As shown, each byte 301-306 is designated to hold a particular type of infomnation. Within each byte, the infor- 
mation may be represented by individual bits or a group of bits. For example, ByteO 301 Is designated to hold the 
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Operation Code for a particular command. The Operation Code consists of a Group code and a Command code, thus 
within ByteO 301 , 5 bits (BitO - Bit4) are used to represent the Command code, and 3 bits (Bit5 - Bit7) are used to 
represent the Group code. 

[0029] The command codes that are available or used in SPTCCP are dictated by both the SCSI committee and the 
5 target device, in this case MSG. In an embodiment of this invention, there are four mandatory command codes asso- 
ciated with MSC. Each of these commands Is sent to the device by populating the Cdb structure with appropriate 
parameters. This means that ByteO will be populated with the appropriate command for MSC. The following table 
summarizes commands for camera devices. The camera device category is one of the device types (such as Direct- 
access Devices, Printer Devices, and Scanner Devices) defined in the SCSI-2 specification. These command and 
10 operations may also be extended in the future. The following are operation codes that can be supported by MSC 
devices: 









TEST UNIT READY 


OOh 


M 


SEND DIAGNOSTIC 


IDh 


M 


REQUEST SENSE 


03h 


M 


INQUIRY 


12h 


M 


READ INFO 


EOh 


M 


WRITE INFO 


Elh 


O 


START S rOP CAPTURE 


E2h 


O 


RESET DEVICE 


DFh 


O 


Key: M - command implementation is mandatory for SPTCCP. 

O = command implementation is optional, but recommended for SPTCCP. 



[00301 This list of operation codes can be extended by vendors to define new functions. However, the above codes 
nnust behave as defined in order for a device to be considered an SPTCCP device. 

30 [0031] Also with reference to FIG. 3, Byte1 (302) is the storage location for the Logical Unit Number (LUN) of the 
target device. Because this invention uses SCSI type connmands, there is a need to conform to SCSI standards. There 
is a requirement within SCSI protocol that each device must have a unique identification on the network and this address 
is referred to as the LUN, and typically ranges from 0-15. Byte2 (303) is the storage location for the first of three 
parameters that can be passed by a Cdb. In one embodiment of this invention, that location is used to store Page 

35 Code, a memory address. Byte3 (304) is normally reserved but is sometime used depending on the command to store 
the lo-byte of a code. Byte4 (305) holds the information on the length of any data that may be associated with the 
underlying command. A discussion to be found later on in this document about the four commands will better illustrate 
this concept. Byte5 (306) holds control type of information which consists of a link bit, a flag, a reserved number of bits 
and information that is specific to the vendor. 

40 [0032] As previously discussed, for each of the previously mentioned SCSI command codes used in SPTCCP there 
are specific entries that are made in the Cdb and in some cases there is also a data buffer structure and a reply structure 
associated with the command. The format and content of these entries and structures define SPTCCP. As such, to 
more fully describe the protocol for communicating and controlling MSC devices, it is necessary to discuss some 
specific commands and responses in terms of how the commands are structured within the Cdb buffer and what pa- 

45 rameters are provided by and between the initiating device I.e. the PC, and the target device i.e. MSC. While the 
general content of the Cdb associated with each command will not be discussed in any great detail, some parameters 
may be commented on because of a unique feature or importance to the protocol. It is understood by those skilled in 
the art that variations of these specifications are within the scope of the invention 

[0033] The first of such commands for MSC is Test Unit Ready which is designated by a specific hexadecimal code 
50 - OOH. This command reports whether a target device is ready to execute commands. As discussed earlier, the first 6 
bytes of the Cdb are populated and structured with a specific layout. The following layout describes the Cdb associated 
with the Test Unit Read command. 



55 
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^^^^ 


ByteO: Operation Code 


OOH 


Bytel : Logical Unit Number 


LUN 


Reserved 




Byte2: Parameters 1 


Reserved 


Byte3: Parameters 2 


Reserved 






Byte4: Parameters 3 


Reserved 


ByteS: Control field 


Vendor Specific | 


Reserved 


1 Flag 1 LUIK 



10 



15 



[0034] Within SPTCCP this Is the simplest command because it has very limited responses and it also has no re- 
quirement for a data buffer. The control field ByteS is set to zero as there is little need for any vendor linked commands. 
Test Unit Ready returns a status code of OOH (Good) if the device is ready to execute commands or it returns 01 H 
(Check Condition) if the device is not ready. 

[0035] The second IVISC command is Inquiry, which is designated by the hexadecimal code-12H. This command 
requests that the target device, in this case MSC identify the device manufacturer, model information, senal number, 
and other such information. In this case, the first 6 bytes of the Cdb are populated and structured with the following 
layout: 



20 



25 









ByteO: Operation Code 


12H 


Bytel: Logical Unit Number 


LUN 1 Reserved 1 ^"^^^ 


Byte2: Parameters 1 


Page Code 


Byte3: Parameters 2 


Reserved 


Byte4: Parameters 3 


Allocation length 


ByteS: Control field 


Vendor Specific ( Reserved 1 FJag | Link 



30 



35 



[0036] As previously noted, the protocol and method of this invention are applicable to other devices. As such, the 
various commands that are being discussed can also be tailored to a specific device. In this instance, for MSC devices, 
the Inquiry command is recommended to be implemented as two inquiry cases, wherein specific bits in the layout 
shown above are set to predetermined values. One case is the standard query comrfiand, wherein BitO of Byte 1 the 
EVPD is set to 0 and Byte2 the Page Code is also set to 0. The other case is the unit serial number command where 
the EVPD is set to 1 and the Page Code Is set to 80H. 

[0037] Each of these command cases generates a different response from the MSC device. In particular, the standard 
query command returns a data buffer that has the following data structure: 











0 


Peripheral qualifier 


Device type code 


1 1 


RMB 1 Device type modifier 


2 


ISO version 


ECMA version || ANSI approved version 


3 


AENC 1 TmiJUi' 


Reserved I Response data format 



4 


Additional data length 


5 


Reserved 


6 


Reserved 


7 


RclAdr 1 Wbus32 | Wbujl6 | Sync || Linked | Reserved | CmdQue | SftRe 


8-15 


Vendor identification string 


16-31 


Product identification string 


32-35 


Product revision level string 


36-55 


Vendor-specific information string 


56-95 


Reserved 


96-end 


Vendor-specific data 
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[0038] It should be noted that the definitions and meanings of the indicated fields in the structure above conform to 
standard SCSI2 specifications. The details of SCSI2 specifications are beyond the scope of this application and as 

such will not be discussed in any detail. 

[0039] In the case of the unit serial number command, the returned page also conforms with SCSI2 specifications 
and has the following data structure: 



10 



15 







6 1 


Peripheral qualifier | Device type code 


1 1 


Page Code (80H) 


2 


Reserved 


3 


Page length (n-3) 


4 


Product serial number 


N 



20 



25 



[0040] Here again, the layout and content of the returned data structure is dictated by a standard that Is beyond the 
scope of this document. The particulars of the infomiation contained in the above illustrations and their usefulness are 
known to those skilled in the art. 

[0041] The third MSCcommand is Request Sense, which is designated bythe hexadecimal code 03H. This command 
altows an initiator such as a PC to report error information. The error could be related to a current operation or the 
most recent operation. Information is transferred from the target device such as a camera to the initiator. 
[0042] The content of the various bytes are specific to the target device and detemnine the interpretation of the 
received infomiation. The first 6 bytes of the Cdb are populated and structured with the following layout: 









ByteO: Operation Code | 


03H 


Byte 1 : Logical Unit Number 


LUN Reserved 


Byte2: Parameters 1 


Reserved 


Byte3: Parameters 2 


Reserved 


Byte4: Parameters 3 


\ Allocation Length 


ByteS: Control field 


1 Vendor Specific | Reserved 


1 Flag Link 



30 



35 



[0043] Request sense by sending the command to the target. The response from MSC+ device should follow SCSI- 
2 specification, but only sense data corresponding to Error Codes 70h is required to be implemented. For SPTCCP 
devices, the sense data fomriat is illustrated in the following table. 



40 



45 



50 
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ByteO: 


Valid=0 pTOh 


Bytel: 


Reserved 


Byte2: 


Reserved | Sense Key=9h 


Byte3«6: 


Information 


Byte7: 


Additional sense length (n-7) 


Byte8-ll: 


Command-specific information 


Byte 12 




Additional sense code = 80h 


Bytel 3 




Additional sense code qualifier - ResponseCode 


Bytel 4 


1 Field replaceable unit code = 0 


Bytel 5-17: 


Sense-key specific = 0 


Bytel 8-n: 


Additional sense bytes 



[0044] A Valid bit of zero indicates that the information filed is not as defined in the SCSI-2 specification. Since 
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camera devices is not included in SCSI-2 specification yet, and the device-specific infomnation field is not defined in 
this docunnent. the Valid bit should be set to zero by the target. 

[0045] The combination of Additional sense code and Additional sense code qualifier is used to Indicate the error 
condition. When issuing SPTCCP specific commands (EOh, E1h. E2h. DFh). Sense Key should be set to 9h and 
Additional Sense Code Is set to 80h to denote vendor-specific, and the Additional sense code qualifier is defined in 
the following table: 



10 



15 



20 



25 









OK 


0x02 


General Error 


0x05 


Operation Not Supported 


0x06 


Parameter Not Supported 


OxOA 


DeviceProp Not Supported 


OxOC 


Store Full 


OxOF 


Access Denied 


0x11 


SeJfTest Failed 


0x16 


Invalid Code Format 


0x18 


Capture Already Tenninated 


0x19 


Device Busy 


OxlB 


Invalid DeviceProp Format 


OxlC 


Invalid DeviceProp Value 


OxlD 


Invalid Parameter 


All codes greater than 
0x2F 


Vendor-Extended Response Code 



30 



[0046] The fourth MSG command is Read Info, designated by the hexadecimal code-EOH. This command allows an 
initiator such as a PC to request transfer of data from a target device such as a camera.. With this command, the first 
1 0 bytes of the Cdb are populated and structured with the following layout: 



35 



40 



Byte 1 : Logical Unit Number 


LUN 1 Reserved 


Byte2: Parameters 1 | 


SCSI DataTypeCode 


Byte3: Parameters 2 ] 


Reserved 


Byte4: Parameters 3 , 


j Data Type Qualifier 


ByteS: 


Byte6: Parameters 4 


Data transfer length 


Byte7: 


ByteS: 


Byte9: Control field 


Vendor Specific Reserved Flag | Lmk 



45 



[0047] The SCSI DataTypeCode distinguishes between the different types of data that may be transfen-ed between 
the initiator and the target. The types of transfers are specified in the following table: 



50 
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OOh 


Image 




Olh 


Vendor-specific 




02h 


Reserved 




03h 


Reserved 
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,1. 

1 



04h-7Fh 


Reserved 


80h 


Device Infonnation 


Slh 


Device Property Description 


82h 


Device Property Value 


83h-FFh 


Vendor-specific 



[0048] The Data Type Qualifier field provides means to differentiate data transfers of the same data type code. For 
10 SPTCCP devices, it is only used when Data Type Code is 81 h or 82h, where the Data Type Qualifier equals the Device 
Property Code listed later in this document. 

[0049] The data buffer should contain the data in the format determined by the native data type. The native data 
types corresponding to each device property code are also listed In the next chapter of this document: 

15 



mm. 


^^it^^i^ ^ip git^ |Bitai mim fBim. t-Bito^ 


0 


Data Buffer LengSi (n-2) 


4- 




Native Data Type Code of the following data 


3 


4 


Data 


N 
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[0050] The fifth MSC command is Send Diagnostic, designated by the hexadecimal code 1DH. This command re- 
quests the target to perform diagnostic operations on itself. The data transfer direction Is from Initiator to Target. The 
first 6 bytes of the Cdb are populated and structured with the following layout: 

30 









ByteO: Operation Code 


IDh 


Bytel : Logical Unit Number 


LUN 


1 1 Resoved 1 U]fTat DevOfL | UnitOiL 


Byte2: Parameters 1 


Reserved 


ByteS: Parameters 2 


Parameter list length 


Byte4: Parameters 3 






ByteS: Control field 


Vendor Specific 


Reserved Flag Link 



40 [0051] A PF bit of one indicates that the parameters confirm to SCSI-2 standard, a zero means SCSI-1 . 

[0052] A SelfTest bit of one directs the target to complete Its default selftest, a zero requests that the target perform 
the diagnostic operation specified in the parameter list. 

[0053] The sixth MSC command is Write Info, designated by the hexadecimal code - El H. The Write Info command 
sends transfer data from the initiator to the target. This command is defined to use a 10-byte CDB. The data transfer 
45 direction is from Initiator to Target. The first 1 0 bytes of the Cdb are populated and stmctured with the following layout: 



so 
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ByteO: Operation Code 


Elh 


Bytel: Logical Unit Number 


LUN Reserved 


Byte2: Parameters 1 


SCSI DataTypeCode 


Byte3: Parameters 2 


Reserved 


Byte4: Parameters 3 


Data Type Qualifier 




ByteS: 






Byte6: Parameters 4 


Data transfer length 




Byie7: 






ByteS: 






Byte9: Control field 


Vendor Specific Reserved 


1 Fl^ 1 Link 



75 [0054] The SCSI DalaTypoCode. Data Type Qualifier, and data buffer layout are the same as defined in the READ 
command above. If a SCSI DataTypeCode and a Data Type Qualifier are both defined, but the Data Transfer Length 
is set to zero, then this comnrwnd resets the default value of that particular device property, 

[0055] The seventh MSC command is Start Stop Capture, which is designated by the hexadecimal code - E2H. This 
command requests the target device lo capture images according to the manner specified through parameters. This 
20 command is defined to use 10-byte CDS. The data buffer, if specifically defined by vendor, has its transfer direction 
as from Target to Initiator . The first 1 0 bytes of the Cdb are populated and stmctured with the following layout: 





f Bit^^lBiTOIigi^ffiiM ffi^affil^iiMM^ 


ByteO: Operation Code 


E2h 


Bytel: Logical Unit Number 


LUN Reserved 


Byte2: Parameters 1 


Capture Type Code 


ByteS: Parameters 2 


VSP II Reserved 


Byte4: Parameters 3 


Capture Format Code 


ByteS: 


Byte6: Parameters 4 


Optional Vendor specific parameter Buffer Loig^. 


Byte7: 


ByteS: 


Byte9: Control field 


Vendor Specific | Reserved Flag | Link 



[0056] The Capture Type Code defines the behavior of the capturing functions on the target: 







0 


Capture a single image 


1 


Initiate Open Capture 


2 


Terminate Open Capture 



45 

[0057] The capture format code, if non-zero, will advice the device the Initiator preferred capture fomiat. If the target 
is unable to capture in that format, il should return error and set the response code to be "Operation Not Supported". 
If the capture fonnat code is zero, the target will capture in its default fomnat. Clearing VSP bit and Parameter 4 to 
indicate that there is no vendor-specific parameter buffer. The VSP bit of 1 indicates that Parameter 4 has meaningful 
so vendor specific parameter buffer. This parameter could be useful, for example, if vendor wants to use it to communicate 
the status and location of the captured picture file on the device. 

[0058] The eighth MSC command is Reset Device, which is designated by the hexadecimal code - E2H. This com- 
mand requests the target to reset its state to the default state. This command is defined to use 6-byte CDB.. The first 
6 bytes of the Cdb are populated and structured with the following layout: 

55 
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B>4eO: Operation Code 1^^^ 



Bytel: Logical Unit Number 


LUN Reserved 


Byte2: Parameters 1 


Reserved 



Bvte3: Parameters 2 


Reserved 


Byte4: Parameters 3 


Reserved 


ByteS: Control field 


Vendor Specific Reserved | Flag | Link 



[0059] This is a simple command with no data buffer. 
15 [0060] Earlier in this document, there were references made to operational codes, response codes and property 
codes. This portion of the document will provide some additional detail on those codes. Operation codes are primarily 
relevant for the Mode Select and Mode Sense command. There are a limited number of allowable Operation Codes 
for an MSG device. Some codes and the associated relevant operations are shown below: 







0x1001 


GetDevicelnfo 


0x1014 


GetDevicePropDesc 


0x1015 


GetDevicePropValue 



[0061] With regard to response codes, SPTCCP utilizes a subset of PIMA PTP command codes and datatypes, and 
also provides its own selections and extensions. The response codes within SPTCCP are also adapted from the PTP 
specification although only a subset of the original response codes are used. The following table illustrates current 
30 response codes and the associated descriptions that are supported by SPTCCP. 



so 



|ResjR§p'sfeC6de|^p3 




0x01 


OK 


0x02 


General Error 


0x05 


Operation Not Supported 


0x06 


Parameter Not Supported 


OxOA 


DeviceProp Not Supported 


OxOC 


Store Full 


OxOF 


Access Denied 


0x11 


SelfTest Failed 


0x16 


Invalid Code Format 


0x18 


Capture Already Terminated 


0x19 


Device Busy 


OxlB 


Invalid DeviceProp Format 


OxlC 


Invalid DeviceProp Value 


OxlD 


Invalid Parameter 


All codes greater than 


Vendor-Extended Response Code 


0x2F 





[0062] In addition to the above described codes, there are four other categories of codes supported by PIMA PTP 
namely, Event codes, Device property codes, Object Format codes and Data type codes. Each of these code categories 
55 enable certain type of Information to be obtained and exchanged between the initiating and target devices. To the 
extent that a particular category Is either supported or not supported within SPTCCP this document will identify such 
categories but will not provide the details of the specific category since this infomnation can be found in other materials 
that define PTP commands, such as PIMA 15740 Version 1.0 - Photography Electronic still picture imaging Picture 
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Transfer Protocol for Digital Still Photography Device. This source and other similar sources that define PTP commands 
are expressly incorporated in this document. 

[0063] SPTCCP does not support events communication between the Initiator and the Target as does PTP there are 
therefore no Event Codes defined within SPTCCP On the other hand, device property codes, also known as Device- 
PropCode as previously discussed, describe the properties of the target that might be set or retrieved through SPTCCP. 
The following codes and description are an illustrative list of currently supported device property codes: 





^^!^^^^^^^^^^^^^^ 




Undefined 


0x5001 


BatteryLevel 


0x5002 


FunctionalMode 


0x5003 


ImageSize 


0x5004 


CompressionSetting 


0x5005 


WhiteBalance 


0x5006 


RGB Gain 


0x5007 


F-Number 


0x5008 


FocalLength 


0x5009 


FocusDistance 


0x500A 


FocusMode 


Ox500B 


ExposureMeteringMode 


Ox500C 


FlashMode 


Ox500D 


ExposureTime 


Ox500E 


ExposureProgramMode 


Ox500F 


Exposurelndex 




0x5010 


ExposureBiasCompensation 


0x5011 


DateTime 


0x5012 


CaptureDelay 


0x5013 


StillCaptureMode 


0x5014 


Contrast 


0x5015 


Sharpness 


0x5016 


DigitalZoom 


0x5017 


EffectMode 


0x5018 


BurstNumber 


0x5019 


Burstlnterval 


Ox501A 


TimelapseNumber 


0x501B 


Timelapselnterval 


0x501 C 


FocusMeteringMode 


Ox501D 


UploadURL 


0x501E 


Artist 


0x50 IF 


Copyrightlnfo 


All other codes with 


Reserved 


MSN of 0101 




All codes with MSN 


Vendor-Extended Response Code 


of 1101 





[0064] SPTCCP does not support the data object concept of PTP. However, ObjectFonnatCodes are used with Get- 
Devlcelnfo operation to get information on the Innage storage file fonnat. The following table illustrates available and 
supported object format codes. 
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25 



^^^ObjcctForiiiatS 








0x3000 


A 


Undefined 


Undefined 


0x3001 


A 


Association 


Association (e.g. folder) 


0x3002 


A 


Script 


Device-model-specific script 


0x3003 


A 


Executable 


Device-model-specific binar>' executable 


0x3004 


A 


Text 


Text file 


0x3005 


A 


HTML 


HyperText Markup Language file (text) 


0x3006 


A 


DPOF 


Digital Print Order Format File (text) 


0x3007 


A 


AIFF 


Audio Clip 


0x3008 


A 


WAV 


Audio Clip 


0x3009 


A 


MPS 


Audio Clip 


0x300A 


A 


AVI 


Video Clip 


0x3 OOB 


A 


MPEG 


Video Clip 


0x300C 


A 


ASF 


Microsoft Advanced Streaming Format (video) 


0x3800 




Undefined 


Unknown Image Format 


0x3801 


I 


EXIF/JPEG 


Exchangable File Format, JEIDA standard 


0x3802 


1 


TIFF/EP 


Tag Image File Format for Electronic Photography 


0x3803 


1 


FlashPix 


Structured Storage Image Format 


0x3804 




BMP 


Microsoft Windows Bitmap File 


0x3805 




CIFF 


Cannon Camera Image File Format 


0x3806 




Undefined 


Reserved 


0x3807 




GIF 


Graphics Interchange Format 


0x3808 




JFIF 


JPEG File Exchange Format 


0x3809 




PCD 


PhotoCD Image Pac 


0x3 80 A 




PICT 


QuickDraw Image Format 



30 
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Ox380B 


I 


PNG 


Portable Network Graphics 


Ox380C 


1 


Undefmed 


Reserved 


0x38OD 


I 


TIFF 


Tag Image File Format 


Ox380E 


1 


TIFF/IT 


Tag Image File Format for Information Technology 
(graphics arts) 


0x380F 


I 


JP2 


JPEG2000 Baseline File Format 


0x3810 


I 


JPX 


JPEG2000 Extended File Format 


All other 


Any 


Undefmed 


Reserved for future use 


codes with 








MSN of 00 11 








All codes 


Any 


Vendor- 


Vendor-Defmed 


with MSN of 


Defined 




ion 









[0065] Another adaptation from PTP specification is the Data type codes. The datatype codes within SPTGCP contain 
some extensions for MSG specific structures. All data types use Big-Endian byte order in memory. The following table 
lists for illustrative purposes, supported datatype codes and their associated descriptions: 
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0x0000 




Undefined 


0x0001 


INT8 


Signed 8 bit integer 


0x0002 


UINT8 


Unsigned 8 bit integer 


0x0003 


INT16 


Signed 16 bit integer 


0x0004 


UINT16 


Unsigned 1 6 bit integer 


0x0005 


rNT32 


Signed 32 bit integer 


0x0006 


UINT32 


Unsigned 32 bit integer 


0x0007 


INT64 


Signed 64 bit integer 


0x0008 


UrNT64 


Unsigned 64 bit integer 


0x0009 


INT128 


Signed 128 bit integer 


OxOOOA 


UrNT128 


Unsigned 128 bit integer 


0x4001 


AINT8 


Array of Signed 8 bit integer 


0x4002 


AUrNT8 


Array of Unsigned 8 bit integer 


0x4003 


AINT16 


Array of Signed 16 bit integer 


0x4004 


AUrNT16 


Array of Unsigned 16 bit integer 


0x4005 


ArNT32 


Array of Signed 32 bit integer 


0x4006 


AUINT32 


Array of Unsigned 32 bit integer 


0x4007 


AINT64 


Array of Signed 64 bit integer 


0x4008 


AUINT64 


Array of Unsigned 64 bit integer 


0x4009 


ArNT128 


Array of Signed 128 bit integer 


0x400A 


AUrNT128 


Array of Unsigned 128 bit integer 


OxFFFF 


STR 


Variable-length Unicode String 


Above are PTP defim 


zd data tvve code, below are SPTCCP extended data code: 


0x8001 


REAL 


Contains two rNT32 integers 
{numerator,denomenator) 


0x8002 


StnictDevicelnfo 


Devicelnfo structure 


0x8003 


StrDateTime 


1SO8601 date time string in Unicode, 
"YYYYMMDDThhmmss.s" 



35 



[0066] In SPTCCP, Real numbers types as shown in the table above are generally stored as two parts within a 
structure. The numerator and denominator are members of the structure. The structure for real numbers can be defined 
as follows: 



40 



typedef struct ^REAL { 

UINT32 numerator; 
UINT32 denominator; 

} structREAL; 



45 
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[0067] As indicated in the data types table above, another type that is use for storing important device infonnation 
is a structure that is returned through the GetDevicelnfo operation that was previously discussed. The structure is of 
variable length but it is recommended in an embodiment of this invention that vendors limit the size of this structure to 
be smaller than 260-1 6-1 6 = 228 bytes. This is because earlier versions of Windows limit the data buffer size to 260-1 6 
for lOCTL commands, and SCSI commands will also need at least 16 bytes for Mode Page headers. Although other 
implementations of this protocol may have no buffer size limit, the act of limiting the size will help the device to get 
backward compatibilrty. The device infomriation structure may be defined as follows: 
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typedef struct _DeviceInfo { 



UINT16 


StandeirdVersion; 


UrNT32 


VendorExtensionID; 


UINT16 


VendorExtensionVersion; 


STR 


VendorExtensionDcsc; 


UINT16 


FunctionalMode; 


AUINT16 


OperationSupported; // OperationCode Array 


AUINT16 


EventsSupported; // EventCode Array 


AUINT16 


DevicePropertiesSupported; // DevicePropCode Array 


AUINT16 


CaptureFormats; // ObjectFormatCode Array 


AUINT16 


ImageFormats; // ObjectFormatCode Array 


STR 


Manufacturer; 


STR 


Model; 


STR 


DeviceVersion; 


STR 


SerialNumber 



} structDevicelnfo 



[0068] The required content of this structure is self evident from the named members above to one skilled in the art. 
[0069] The present invention has been described in connection with exemplary embodiments which are intended to 
25 be illustrative rather than restrictive. For example, the invention has been described in the context of controlling a Mass 
Storage Class Digital Camera (MSG) from within the operating system of a PC on a USB medium. The protocol could 
just as easily relate to many other types of communications medium, such as a network cable or other forms of con- 
nectivity between a Digital class storage device and a PC. 

[0070] Altemative embodiments of the present invention will become apparent to those skilled in the art to which it 
30 pertains upon review of the specification, including the drawing figures. Accordingly, the scope of the present invention 
Is defined by the appended claims rather than the foregoing description. 



Claims 

1 . A method for use in a computing device operating with an operating system for controlling a mass storage class 

digital imaging device comprising: 

providing a control command that is interpretable by the mass storage class digital imaging device; 
packaging said command; and 

transmitting said packaged command to the mass storage class digital imaging device. 

^5 2. A method as recited In claim 1 further comprising receiving said packaged command at the mass storage class 
digital Imaging devk:e. 

3- A method as recited in claim 2 further comprising unpackaging said packaged command, 

so 4. A method as recited in claim 3 further comprising implementing said control command at the mass storage class 
digital imaging devbe. 

5. A method as recited in claim 1 wherein said control command comprises: 

55 a standard Picture Transfer Protocol (PTP) command; and 

extended commands that are specific to the mass storage classs digital imaging device. 
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6. A method as recited in claim 1 wlierein said packaging includes packaging said control command in a SCSI com- 
mand, said packaging comprising: 

providing entries in a SCSI Pass through structure; 

5 

providing entries and values for a command descriptor block within said SCSI Pass through structure; and 
providing data buffers to hold resulting infonmation. 
10 7. A method as recited in claim 1 wherein said transmitting is via a USB protocol. 

8. A method for use in a computing device operating with an operating system for communicating control commands 
between an application program and a USB nnass storage class digital imaging device comprising: 

15 generating a device specific control command in a computing environment upon interaction with the application 

program; 

transmitting said command as a SCSI pass through command via a USB channel to the USB device; 
20 interpreting said SCSI Pass through commands; and 

executing the command on the USB device. 

9. A method as recited in claim 8 wherein said specific control command is one of a plurality of available commands 
25 associated with the USB device and wherein said execution of said command results in at least one action by the 

USB device. 

10. A method for use in a computing system for communicating between an application program and a USB mass 
storage class imaging device for controlling said device wherein infonmation about said device is stored and re- 

30 turned in a data structure comprising: 

a data field containing data representing a fimriware version; 

a plurality of data fields containing data representing vendor extension information; 

35 

a data field containing data representing a functional mode of the device; 
a data field containing data representing supported operations of by the device; 
40 a data field containing data representing supported events relating to communication; 

a data field containing data representing supported device properties, 
a data field containing data representing infonnation capture fomnats; 

45 

a data field containing data representing supported image fomnats; 
a data field containing data representing the manufacturer of said device; 
so a data field containing data representing the model of said device; 

a data field containing data representing the version of said device; and 
a data field containing data representing the serial number of said device. 

11. A method for use in a mass storage class digital imaging device controllable by a computing device, said mass 
storage class digital imaging device receiving a command from the computing device, said command including a 
packaged control command interpretable by the imaging device, said command being unpackaged and Imple- 
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mented to control said mass storage class digital imaging device. 

12. A computer-readable medium having computer-executable instructions for perfomiing the steps recited in claim 1 . 

5 13. A computer system having a memory, an operating system and a central processor, said processor being operable 
to execute the instructions stored on the computer-readable medium of claim 12. 

14. A computer-readable medium having computer-executable instructions for performing the steps recited in claim 8. 

10 15. A computer system having a memory, an operating system and a central processor, said processor being operable 
to execute the instructions stored on the computer-readable medium of claim 14. 

1 6. A computer-readable medium having computer-executable instructions for perfonning the steps recited In claim 1 0 . 

15 17. A computer system having a memory, an operating system and a central processor, said processor being operable 
to execute the instructions stored on the computer-readable medium of claim 16. 

18. A compuicr-roadabie medium having computer-executable instructions for perfomnlng the steps recited in claim 11 . 

20 19. A computer system having a memory, an operating system and a central processor, said processor being operable 
to execute the instructions stored on the computer-readable medium of claim 18. 
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